I'm considering changing the versioning schema for types and maybe even the cli packages so the major version number matches the runtime spec version. Currently we are only incrementing the minor version on each release which is semantically incorrect.

What do you think @Lezek123

Progress from 0.1.0 to 0.2.0 should be correct for initial development releases, during which there are many breaking changes and backward compatibility may not be preserved. This is, for example, how @polkadot/api was intially versioned, so in case of 0.x.y, x would mean something like a "major release" (this is also how it's treated by npm, so ie. ^0.1.0 will not catch 0.2.0 but ^1.1.0 will catch 1.2.0: https://semver.npmjs.com/).

If we decide we're not in "initial development" stage anymore, we could move to 1.0.0 and then increment the first digit after each release. It would be nice to have the major version match runtime spec version, but moving from 0.1.0 to 3.0.0 may also be a little confusing.

Progress from 0.1.0 to 0.2.0 should be correct for initial development releases, during which there are many breaking changes and backward compatibility may not be preserved. This is, for example, how @polkadot/api was intially versioned, so in case of 0.x.y, x would mean something like a "major release" (this is also how it's treated by npm, so ie. ^0.1.0 will not catch 0.2.0 but ^1.1.0 will catch 1.2.0: https://semver.npmjs.com/).

If we decide we're not in "initial development" stage anymore, we could move to 1.0.0 and then increment the first digit after each release. It would be nice to have the major version match runtime spec version, but moving from 0.1.0 to 3.0.0 may also be a little confusing.

Okay that sounds reasonable. So lets stick with current convention 👍